\documentclass[10pt]{article}
\usepackage{graphicx}
\usepackage{fullpage}
\usepackage{palatino}
\usepackage{listings}
\usepackage{multicol}
\usepackage{xspace}

\renewcommand{\floatpagefraction}{0.99}

\newcommand{\epsfig}[4]{
\begin{figure}[tbp]
 \begin{center}
% \resizebox{#2}{!}{\includegraphics{#1}}
   \includegraphics[#2]{#1}
  \caption{#3}
  \label{#4}
 \end{center}
\end{figure}}


\newcommand{\twoepsfig}[8]{
\begin{figure}[tb]
%\vspace*{-0.3cm}
\begin{center}
\begin{minipage}[b]{8cm}
  \begin{center}
  \resizebox{0.9 \textwidth}{!}{\includegraphics{#1}}
%\vspace*{-0.3cm}
    \caption{#3}
    \label{#4}
  \end{center}
\end{minipage}\hspace*{0.2cm}\begin{minipage}[b]{8cm}
  \begin{center}
    \resizebox{0.9 \textwidth}{!}{\includegraphics{#5}}
%\vspace*{-0.3cm}
    \caption{#7}
    \label{#8}
  \end{center}
\end{minipage}
\end{center}
%\vspace*{-0.4cm}
\end{figure}
}
\sloppy

\newlength{\colW}

%%%
\newcommand{\fixme}[1]{{\framebox[\width]{{\sc\bf #1}}}}
\newcommand{\diet}{\textsc{Diet}}\xspace
\newcommand{\eg}{{\it e.g., }}
\newcommand{\ie}{{\it i.e., }}

%%%\renewenvironment{verbatim}{\begin{lstlisting}}{\end{lstlisting}} 

\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
%\usepackage[french]{babel}
 
\title{Ninf-Gxx status as of Feb. 2009}

\author{Hidemoto Nakada, (hide-nakada@aist.go.jp), AIST/CNRS}

\begin{document}
\twocolumn[\maketitle]

\section{Introduction}
Ninf-Gxx is a prototype implementation of GridRPC API (OGF GFD.52) \cite{gridrpc-doc}
and new Data Handle API, which is proposed by DIET team from INRIA.
The goal of the implementation is not 'REAL' use. 
It is meant for just a sanity check of the API definition; i.e. make sure that 
the API is at least implementable, and give feedback on the API definition.

The implementation is not complete yet and some capability defined 
in the Data Handle API is missing. But I believe it is still useful to 
publish this to share in the WG.

\section{Implementation Details}

\subsection{Overview}
Ninf-Gxx is based on Ninf-C\cite{ninf-c-hpcasia04}, which is a variant of Ninf system,
based on Condor. 
%
\footnote{Note that Ninf-Gxx and Ninf-C is completely independent implementation
from our primal product Ninf-G5. While Ninf-G5 also can use
Condor as job invocation mechanism, nothing is shared between Ninf-Gxx and Ninf-G5.
Ninf-Gxx is written in C++ while Ninf-G is written in C.}
%
Ninf-Gxx does *not* use any network connection. All the communication between 
client and remote executables are performed via files.
The files are automatically transferred between client node and 
remote node by Condor. 

\subsection{How it works}

The remote executable, i.e. the server, is straight forward.
On grpc\_call, the client basically passes grpc\_data\_t structures
to the remote executable. The remote executable retrieves 
the data from the locations specified in the grpc\_data\_t structures,
and writes back the results to the specified location.

The client is slightly complicated, because of the ``memory'' scheme,
which denote the data in the client side memory.
Since I did not have data management layer that can handle
``memory'' protocol, I had to craft a trick.
Data on memory will be written out on the client file system,
and the URL denote the memory will be modified so that
it denote the data on the file system using special URL scheme
called ``rfile'' (means relative file) instead of ``memory'' protocol.

Figure \ref{fig0}-\ref{fig8} demonstrate how the system works,
assuming a program shown in Figure \ref{sample}.
The function ``add'' has two inputs ( A and B ) and one output (C).
A is located in the client memory, and B is on a server ``somewhere''.
We'd like to have the result in memory area C.


\subsection{Data Management Layer}
To access data stored in the location denoted by some URL, 
I used a Data Management Layer proposed by Ga\"{e}l Le Mehec, DIET team, ENS Lyon.
The layer is stored in ``libDataMngt''.

\section{Limitations}

\begin{itemize}
\item For URIs, only a few protocols are supported, i.e., ``file'', ``http'', and ``memory''. 
``ftp'' might work , depending on curl implementation.
\item Protocol ``memory'' is only supported for ``localhost''.
\item container functions are not implemented.
\item Data transfers are blocking. Therefore, grpc\_data\_wait returns immediately.
\item grpc\_free does not free anything. It is equivalent with grpc\_unbind.
\item grpc\_get\_status is poorly implemented.
\end{itemize}

\section{Installation and Test}

\subsection{Prerequisite}
The followings have to be installed in advance. 
\begin{itemize}
\item C++ complier\\
We have tested it on g++ 4.X only.


\item Condor\\
Yes, Ninf-Gxx is based on Ninf-C which is written for Condor!
You have to have Condor installed on your computer to test 
Ninf-Gxx.

\item Boost library\\
Boost is a well known C++ library set that provide
a lot of missing functionality in the C++ standard library.

Ninf-Gxx uses several capability of boost, such as
regular expression, format, and foreach loop.

<li> libcurl <br>
cURL is a common library to access servers in several protocols,
including http, and file.
While most Linux distributions includes this as a default.
header files might be missing. In that case, you need to 
install libcurl-dev or something like that.

Ninf-Gxx (or the Data Management Library underneath) is 
relying on libcurl for accessing data stored on the net.
\end{itemize}

\subsection{Directory Structure}
Figure \ref{dirstructure} shows the directory structure
of the package

\begin{figure*}
\begin{verbatim}
---+- bin              : command goes here
   +- lib              : libraries
   +- include          : header files
   +- libDataMngt      : data management layer 
   +- pythonServer     : python http server for test
   +- makefiles        : makefiles 
   +- src --+- Client  : client codes
   |        +- Gen     : IDL compiler
   |        +- Library : common library
   |        +- Stub    : Remote Executable codes
   +- test -+- matmul  : testing
   +- doc              : documentation
\end{verbatim}
\caption{Directory structure}
\label{dirstructure}
\end{figure*}

\subsection{Install}
\begin{itemize}
\item Download the tarball and untar.

\begin{lstlisting}[language=C,basicstyle=\footnotesize\tt]
> tar zxvf ngxx.tar.gz
\end{lstlisting}

\item copy a Makefile and a template file.
\begin{lstlisting}[language=C,basicstyle=\footnotesize\tt]
cp makefiles/Makefile.linux makefiles/Makefile
cp makefiles/template.linux makefiles/template
\end{lstlisting}

\item modify makefiles/template. 
Specify CONDOR\_PATH and CONDOR\_CONFIG and boost library name.

\item modify bin/configvals.csh.
You may want to modify the boost regular expression library name.

\end{itemize}

\subsection{test}
\begin{itemize}
\item Go test/matmul.
\item run Make.
\item ./MatMulGrpcDataMemory -config test.conf
\end{itemize}

\subsection{Python http Server}
To test http protocol, a http server capable of handling PUT request.
Directory ``pythonServer'' contains PuttableHTTPServer.py, which is
a mini http server for testing purpose.


\section{How to use}

\subsection{Client}
Writing client should be easy, in theory, since it conforms the
Grid RPC APIT and Grid RPC Data handle API standards.
You just write a program using the API and compile it
and link it with the library.

For your convenience, a compile driver called ``nccc'' is 
in bin directory. You can use it instead of gcc/g++.
\begin{verbatim}
> nccc yourcode.c
\end{verbatim}

To execute the code you have to have a configuration file
to pass the grpc\_initialize.
The most simple configuration file will be something like the following.
\begin{verbatim}
info_dir = .
\end{verbatim}
This specifies all the info files (described later) will be at the current 
directory. 

\subsection{Remote Executable}

To have remote executable you have to do the followings;
\begin{enumerate}
\item write a IDL file. You can find a sample in test/matmul/matmul.idl.
The syntax is (almost) the same as the one of Ninf-1, described in
\verb|http://ninf.apgrid.org/documents/idl.html|.
\item compile the IDL file with a IDL compiler ncgen in bin directry.
This will create a Makefile, info file that stores the function interface information, 
and source codes for the main routine of your remote executables.
\item execute ``make'' on the generated makefile.
\end{enumerate}


\section{Conclusion}
As stated in 'Introduction', Ninf-Gxx is not meant to be used,
but you can try to 'feel' the Data handle API. 
Feedback will be greatly appreciated.


\section*{Acknowledgement}
I'd like to thank Yves Caniou, Eddy Caron, and Ga\"{e}l Le Mehec, for
the discussions we had on the specification and the implementation.


\bibliographystyle{unsrt}
\bibliography{bib}


\begin{figure*}[t]
\begin{lstlisting}[language=C,basicstyle=\footnotesize\tt]
grpc_function_handle_init(&handle,"Server","add");
grpc_data_init(&dA, 
              (const char * []){"memory:///A", NULL}, 
              NULL,
              GRPC_DOUBLE, (size_t []){3, 3, 0},
              (grpc_data_mode_t []){GRPC_STICKY, GRPC_END_LIST});

grpc_data_init(&dB, 
               (const char * []){"http://somewhere/B", NULL}, 
               NULL,
               GRPC_DOUBLE, (size_t []){3, 3, 0},
               (grpc_data_mode_t []){GRPC_PERSISTENT, GRPC_END_LIST});

grpc_data_init(&dC, 
               NULL, 
               (const char * []){"memory:///C", NULL}, 
               GRPC_DOUBLE, (size_t []){3, 3, 0},
               (grpc_data_mode_t []){GRPC_PERSISTENT, GRPC_END_LIST});
grpc_call(&handle, &dA, &dB, &dC);
\end{lstlisting}
\caption{Sample Program}
\label{sample}
\end{figure*}

\epsfig{figs/ngxx0.eps}{scale=0.3}{
  The initial condition.
}{fig0}
\epsfig{figs/ngxx1.eps}{scale=0.3}{
  On grpc\_call, 
  the clients write out data handles and data A on to file system as files.
  Note that the data handle now use ``rfile'' instead of ``memory'' scheme.
  Also note that file ``C'' is not actually exists at this time.
}{fig1}
\epsfig{figs/ngxx2.eps}{scale=0.3}{
  The client initiate condor\_submit. Condor takes the
  files and move them to the temporary working directory on Server.
}{fig2}
\epsfig{figs/ngxx3.eps}{scale=0.3}{
  The remote executable module read the data handle.
}{fig3}
\epsfig{figs/ngxx4.eps}{scale=0.3}{
  The remote executable reads the actual data using the handle. A is read from
  the file system with ``rfile'' scheme, and B is read from ``somewhere'' with
  ``http'' scheme.
}{fig4}
\epsfig{figs/ngxx5.eps}{scale=0.3}{
  The remote executable perform ``add'' operation on A and B, and generate C.
}{fig5}
\epsfig{figs/ngxx6.eps}{scale=0.3}{
  The remote executable write C on to the working directory as file ``C''.
}{fig6}
\epsfig{figs/ngxx7.eps}{scale=0.3}{
  On termination of the remote executable, Condor takes the output file ``C'' and
  move back to the working directory on the client.
}{fig7}
\epsfig{figs/ngxx8.eps}{scale=0.3}{
  The Ninf-Gxx client takes the output file and read into the memory.
}{fig8}


\end{document}
